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(608) wHhout inpairing periodical drnability of proc- 
esses designed tor executing continuous media 
processing. When a process requests the use of the 
^shared resource, abortlan of that process is first disa- 
"bled bythe process itseH by using an abort disable func- 
tion (21) and then preemption of the same process is 
disabled by means of a preempt control module (30), 
wtiereupon the process enters a processing executed 
by using the shared resource (608). Upon ccmpietiai of 
the processing for the shared resource (608), tie proc- 
ess is immediately set to a preenpt-endbled slate by 
means of a preeirpi control module (30). After comple- 
tion of all the proceeaings, the abort-disabled slate la 
finally cleared by using a disabled-abort clear function 
(22). Upon occurrence of fbrcitre termination of a proc- 
ess In the abort-disabled state thereof, execution of this 
process is continued until the abort-dlsabied state is 
cleared, and the process Is terminated forcibly after the 
abort-disabled state has been cleared. 
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Description 

BACKGROUND OF THE INVENTION 

The present invention relates to a method of exe- 
cuting processes in an operating system controlling a 
oornputer system and a method of accessing a resource 
in the computer system. More particularly, the invention 
is concerned with a method of executing processes tiy 
using a shared resource in an operating system provid- 
ing a multiprocessor or multiprocessing environn!>ent. 

In the operating system capable of providing the 
multiprocessing environment for executing a plurality of 
processes (or tasks) in parallel on a tme-diviston t>asis, 
it is required to execute ttie processes while perfbrming 
mutual exdusfve control or management so that the 
resource shared mnong the proceesea is not simultane- 
ously allocated Id a plurality of praoeases. As a means 
for realizing such mutual exclusive management, there 
is Iffiown and widely adopted in the operating system 
(OS) a (wocedure referred to as 'lock control". 

In the lock control, a flag indicating that a corre- 
sponding shared resource is being used is set for each 
of the shared resources. When one of the processes is 
going to perform a processing by using a given one of 
the shared resources, it is checked whether thef lag cor- 
responding to this shared resource is set by any other 
process. Unless the flag is set by the other process, the 
given one process can use exclusively the shared 
resource while setting the flag indicating that the 
resource is occupied. This operation is typically referred 
to as "lock or locking" of the shared resource. Upon 
completion of the processing for the shared resource, 
the process releases the shared resource while reset- 
ting the flag. This operation is refen-ed Id as 'unlock or 
unlocMng" of the shared resource. On the othor hand, 
when the flag corresponding to the shared resource to 
be used is set by any other piocess. the opsrating sys- 
tem sets the one process requesling the use of this 
resource to the waiting or slancfcy statB unlil that shared 
resource has been unlocked. 

At this juncture, let's assume that a process 1 of low 
priority and a process 2 of high priority are executed in 
parallel and that an shared resource A is shared availa- 
bly by these two processes. On this assunption, it is fur- 
ther supposed that the process 1 of low priority has 
locked the shared resource A in the ooirse of using a 
CPU (central processing unit) and that the shared 
resource A has entered into a suspended stale with the 
lock being left validated. In that case, the process 2 of 
high priority assigned with the right lor using Ihe CPU in 
succession to the process 1 can not use the shared 
resource A, because the resource has been locked by 
the process 1 of low priority. As a consequence, execu- 
tion in succession becomes impossible. 

The problem that Ihe process of high priority is 
Inhibited from execuSan In succession because of the 
lock secured by the process of low priority is referred to 
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astheprtority inversion problem. Concerning this prior- 
ity inversion problem, r^erenoe may be made to "PRt- 
ORITY INHERITANCE PROTOCOLS: AN APPROACH 
TO' REAL-TIME SYNCHRONIZAriON" in IEEE 

5 TRANSACTIONS ON COMPUTERS. Vbl. 39, No. 9, 
September 1990, pp. 1175-1185. In the conventional 
operating system known heretofore, when the priority 
inversion takes place, the dormant process of low prior- 
ity acquired and loctod the shared resource is executed 

10 with the topmost priority in order to unlock the shared 
resource so that the process of Ngh priority can be exe- 
cuted as early as possisle. 

On the other hand, the opei^ting system providing 
the multiprocessing environment is impaned with a 

15 function for protecting the resource alocated to a given 
process against the Illegal access attempted by any 
otiier process. This funcHon is lef en-ed to as the access 
right control or manage ftindlon. The access right con- 
trol or nranagement now under consideration is based 

so on the presumption that the access right can be set on 
a process-by-process bffiis and that a pluielity o1 proc 
esses may simultaneously try to access a computer 
resource. An interface for allowing a user application to 
call Ihe functions of the operating system is ordinarily 

S5 provided and known as "system call". In this conjunc- 
tion, it is noted that when a pointer is used as an argu- 
ment of the system call, designation of an illegal 
address by the user applksttlon may umfaMxably lead to 
destruction of important data resident in the operating 

30 system. To avoid such unwanted situation, an identifier 
is used as the argument in place of the pointer in typical 
one of Ihe access right control or management. 

' In the case of the access right control method in 
which the identifier is used as the argument in the sys- 

35 tern cal issued by the user appication. the operating 
system is required to translate the identifier to an 
address In the resource lor maldng access to the 
resource. In this context, the Amplest one of the transla- 
tion methods is a method in which the hash fundion is 

« employed. According to this method, an identifier is 
placed in or assigned to the hash function as a toy, 
whereon the hash value as oblained is used as the 
address. The access right control method relying on the 
hash function will be described b^ow. 

45 

§1. Configuralton 

As is shown in Fig. 1 , the operating system assigns 
a resource identiTier 100 to the hash function (F) 1 01 as 

50 a key to aoqure as the hash value an index "Index" 1 02 
contained in a resource management date tatjte 1 04. As 
is shawm in Fig. 2A. resource management date 105 
^ored in the resoiffce management date table 104 con- 
teins an identifier 201 . a pointer 205 to a resource 103, 

55 a flag 202 indicating presence or absence of a succeed- 
ing Of next resource management date 106, a pointer 
203 to ^e succeeding resource management date 1 06, 
and a pointer 204 to process management date 107. 
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There may arise sued situation that the hash func- 
tion r^ums a same index " Index" for different identifiers 
RID. In that case, cotition between the indexes "index" 
win occur. Accoidingly, the second resource manage- 
ment data 106 et seq. are stored in an overlkw area 
with the address of the second or succeeding resource 
management data 106 being placed in the immediately 
preceding resource managemertt data 105. 

In case the resource is a shared resource, ttiere 
exist a plurality of processes having respective access 
rights for the same Identifier RID. In that case, the point- 
ers to ^e second F»m»ss identifier data 1 08 et seq. are 
placed in the immediately preceding process manage- 
ment data 107. 

The resource management data 105 is shown in 
Fig. 2A while the process management data 107 is 
shown in l^g. 2B. As can be seen in Rg. 2B, Ihe process 
management data 107 is oornposBd of a process identi- 
fier 207, a flag 208 indicating presence or absence of 
the next process management data, and a pointer 209 
to the next process management data. At the end of the 
user application, K becomes necessary to loiow the 
identifier of the process havi ng the access right in order 
to deallocate the resource occufmd by the process. 
Thus, the operating system is provided with a process- 
specific resource identlier list 109 in which a resource 
identifier 1 10 is entered every time when a correspond- 
ing reeource is generalBd or every time ihe access right 
to the shared resource Is acquired. 

§2. Resource Allocalion Proces^g 

Figure 3 is a flow cfiart for iitustraling a resource 



When Bie system call requesting the resource aDo- 
cation is issued toihe operating system lay a user appli- 



allocatlng the resource (step 1000). Subsequemiy. the 
operating system acquires an identifier RIDx definite in 
the system (step 1001} and places the identifier RIDxto 
the hash function as a key. Thus, the index "Index" con- 
tained in the resource management data table 104, i.e., 
the address where the resource management data x is 
stored is oljtained (step 1002). In the case where the 
resource management data x has already been placed 
at the leading location of the area designated by the 



(step 1003), Ihe pointers are fcdowed up from one to 
another (step 100S) so long as ^e flag 202 indicating 
presence or absence of the identifier management data 
105 assumes a value 'ON" (indicating the presence of 
the resource management data 105) [stsp 1004). When 
the resource management data z for which the flag 202 
inoRcating the presence or absence of the succeeding 
identifier managemem data is set to "OFF" is found in 
the couise of following or tracing the pointers, then the 
succeeding identifier management data pres- 
ence/absence flag 202 is set to W (step 1006). Sub- 



sequently, am area for the new resource management 
data X is allocated to the overftow area (step 1007), 
whereupon the pointer 203 to the immediately preced- 
ing resource management data contained in (he 

5 resource managemem data y is placed at the address 
of the resource management data x (step 1 008). When 
ft is found in the step 1 003 that the succeeding identifier 
management data is not stored, the area for the 
resource management data & is assigned to the main 

10 area (step 1009). 

TTie process management data 107 is placed In the 
process management area and the process identiier is 
stored therein (step 1010). At the same time, the identi- 
fier RIDx 207 ie stored in the process-specific identifier 

15 list 1 09 (step 1011). The identifier RIDx 201 . the pointer 
204 to the process management data and the resource 



data X 105 are assigned with respective values, wher- 
eon the flag 202 indieaUng the presence or dbsence of 
20 the succeeding resource managemem data is set to 
■OFP state (step 1012). Then, the identifier RIDx is 
returned to the user application (step 1013). 



When the system call indteating a resource access 
request is issued by the user application to the operat- 
ing system, the latter executes the processing llluslrated 
in Fig. 4. 

90 The operating system assigns the identifier RIDx 
which is the argument of the system call to the hash 
function to obtain the Index of the resource manage- 
ment data 105 (step 1100). Subsequently, the Identifier 
RID contained in (he resource management data 105 
35 located at the Index is compared with the argument 
RIDx (step 1101). When the values of the idenWer RID 
RIDx differ from each oUier and when 
presence or absence of the 
succeeding reeource management data in the resource 
management data 105 is set 'ON", i.e., when the suc- 
ceeding resource management data 105 exists (step 
1 102), the pointer 203 ie followed up to the succeeding 
resource management data (step 1103), whereon tfie 
oomparison between the idemifier and the argument 
mentioned above is again performed (step 1 101). In the 
case where the identifiers RID of all the resource man- 
agement data 1 05 which can be tolowed with the point- 
ers do not coincide wHh the argument RIDx, it is then 
decided that the resource as requested does not exist in 
the system whereupon an error message is relumed to 
the user application (step 1104). On the other hand, 
when coincidence is found between the identifier RID 
contained in the resource management data 105 and 
the argument RIDx in the conparison step 1 101, then 
the process idetrtifier PIDx of Ihe process accessing 
currently the resource is compared with the process 
identifier PID 207 contained in the process manage- 
ment data 107 (step 1 105). When It is found in the step 
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1105 that the values of both the identifiers differ from 
each other and when the flag 208 contained in the proc- 
ess management data 107 and indicating the presence 
or absence of the succeeding process management 
data is "ON" (indicating that the succeeding process 
management data 1 07 exists) (sl^ 1 1 06), the succeed- 
ing pointer 209 is followed to reach the succeeding 
process management data (step 1107), whereon the 
comparison of the process identifiers mentioned abaie 
is again performed (step 1 105). When the process Iden- 
tifiers PID contained in all the resource management 
data 105 which can be followed with the aid of the point- 
ers do not coincide with the argument PIDx, h is then 
decided that the user application issuing the system call 
has no access right to the resource, whereon an error 
message is returned to the user application (step 1 108). 

On the other hand, when the ooinddenoe is found 
between the prooese identifier and the argument In the 
step 1 105, access to the resource Is perfomied by using 
the resource address stored in the resource pointer 205 
contained in the resource management data 105 (step 
1109). 

§4. Resource Deallocat'on Processing 

In the case where a system call requesting the 
deallocation of the resource is issued to the operating 
system from the user application, then the resource 
deaflocation piocesBing Is performed for that resource. 
Additionally, when deallocation of the resources 
becomes necessary due to abnormal termination of a 
process, then the resource deallocation prooesang is 
performed br the resources corresponding to all the 
Identifiers contained in the identifier list specific to the 
process termkialed alswrmaily. The resource dealloca- 
tion processing win be descrbed below by reference to 
Fig. 5. In the first place, the operating system InNbUs or 
block the access to all the resources (step 1200) and 
places the identifier RIDx of the resource to be deallo- 
cated in the hash function as a hey to obtain the Index 
'Index" of the resource management data 105 (step 
1201). Subsequently, the identifier RID contained in the 
resource management data 1 05 stored in the area indi- 
cated by the index is compared with the i<ey or identifier 
RIDx (step 1202). When the values of both the identifi- 
ersdifter from each other and when the flag 202 indicat- 
ing the presence or absence of the succeeding 
resource management data is "ON". i.e., when the suc- 
ceeding resource management data 105 exists (step 
1203), the pointer 203 is followed up to the succeeding 
resource management data (step 1204), whereon the 
identifier comparisai mentioned above is again 
repeated (step 1202). In case the identifiers RID of all 
the resource management data 105 which can be tol- 
Icwed whh the pointers do not coincide with the l<ey or 
identHia^ RIDx, it is ttten decided that «ie resource as 
requested does not exist, whereupon an error message 
is returned to the user application (step 1205). 
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Onttie other hand, when coincidence between both 
the identifiers FDD and RIDx is found in Ihe step 1202, 
the address of the process management data 107 
stared In the poiiiter 204 to ttie process management 

s data is acquired (st^ 1206). When the succeeding 
resource management data 105 easts (step 1207), the 
resource management data 1 05 specified by the identi- 
fier RIDx is released or unlocked (step 1209) after 
changing the string of the pointers 203 to the resource 

10 management data (step 1208). Subsequently, flie 
pointer acquired In the step 1206 is followed and It is 
checked whether or not ihe flag contained in the proc- 
ess management data 107 and indicating the presence 
or absence of the succeeding process management 

15 data is -Ofyl" (step 1210). H the flag Is X>K. the pointer 
209 to the succeeding process management data is 
acquired (step 121 1], whereupon a message indicating 
that the process management data 107 is released or 
dealk>caled and that the identifier RID can no more 

20 used is issued to the user applications. i.e., individual 
processes (step 1212). On the other hand, when it is 
. dedicated in »e step 1 21 0 that the flag 208 indicating 
the presence or absence of the succeeding resource 
man^ement data is 'OFF', tiie final process manage- 
rs ment data 1 07 is released or deallocated, wh ereon the 
message indicating that the identifier RID can no more 
be used is issued to the user application (step 1213). 
which is then followed by the reopening of the access to 
all Ihe resources (step 1214). 

so In conjunction wtth the method deecrtoed above, it 
is noted ttiat even when the index "Index' contained in 
the resource management data table 104 can be 
obtained by assigning an illegal identifier RIDz to the 
hash function as the key, the llegal identifier RIDz can 

3S not be found in the resovce management data 105 
which can be fbllcwed or traced with the index. Conse- 
quently, no resoiffce address can be obtained, render- 
ing the access impoesfale. Further, even if the ilegat 
identifier RIDz should be contained accidentally in the 

40 resource management data 105 traced with the Index, 
the Identifier of the process making access to the 
resource is not stored In the process management data 
107. Consequently, the address of the resouroe can not 
be gained. Thus, IHegal access can be inhlaited or disa- 

45 bled. 

Furthermore, In the resource unlock processing, 
the resource protection can be realized by Inhisiting or 
disiabling all the accesses of the user applications to the 
resource, while Illegal access after ^e resource deallo- 
50 eating can be inhibited by invalidating the identifier, 
releasing the resouroe management data and the proc- 
ess management data which can be traced with the 
indoc and issuing the message infomnlng ihe processes 
of the dealkicaling of the resource. 

55 

SUMfytARY OF THE IMVEfOTION 

In the continuous mecRa processing, operation of a 
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process tor processing data such as animation data is 
accompanied witli periodicity. A process scheduling 
method making use of this feature has already been 
proposed. For more particulars of this method, refer- 
ence may be made to Japanese Patent Application No. 
8-73673. 

In tNe conjunction, it is noted that the priority inver- 
sion problem discussed hereinbefore affects adversely 
the process scheduling method based on the periodicity 
mentioned above as well. By way of example, it is 
assumed that there exist two processes, nam^ proc- 
ess 1 and process 2, for carrying out the continuous 
media processing and that there exists a resource A 
which is shared by mese two processes. In that case, 
when the process 1 and the process 2 attempt to control 
or manage mutually exclusively the shared resource A 
by making use of the lock funclfon, there may arise the 
priority inversion problem, which will impair the periodi- 
cal drivability of the process. 

Further important problem incurred by the priority 
inversion can be seen in that the process having been 
locked, bringing about the priority inversion pr(A)lem. is 
scheduled with highest preference. Thus, it is safe to 
say that the priority inversion proUem exerts adverse 
Mluence even to the periodical drivability of other proc- 
ess partaking in the continuous media processing. 

Under the circurnslartces, in the system designed 
tbr peitomning the oontinuaus media processing, ttiere 
Es conceivable a method ct structuring a computer sys- 
tem without using arry lock at all from the beginning in 
order to evade the priority inversion problem. As a 
method of realizing the exclusive control or mutually 
GKdusive management of the process, such process 
control or management method may be conceived in 
which the process using cunenlly the shared resource 
is allowed Id occupy exclusively the CPU (Central 
Processing Unit) or, to say In another way, ariy other 
process Is inhibited or disabled from being scheduled so 
long as the shared resource is being used a given 
one of the processes. Such control or managing mAhod 
can be realized by adopting a preempt control method 
proposed in Japanese Patent Application No. 8-97997. 
Parenthetically, the preennpt control method concerns 
prevention of a process being executed from being tem- 
porarily suspended (i.e., preempted) by providins inter- 
faces 'preenpt disabling" and \isabled-preenipt 
releasing or clearing', wherein during a period intemen- 
ing between a time point at whteh the preempt disabling 
is vaidated and a time point at which the preempt disa- 
bling is clearad (this period may also be referred to as 
the preempt-disdUed interval), the process in execution 
is prevented from being preempted and tfius can con- 
tinue the execution even when a scheduling request is 
issued from any other process. By virtue of such control, 
it can be ensured that no more than one process can 
use the shared resource at any time. In other words, the 
exclusive control or management of the prooessee can 
thus be realized. 



It is however noted that with the control method 
mentioned above, periodical drivability of the other proc- 
ess may be impaired when the process using the 
shared resource runs over a prolonged duration. 

s Let's consider, for acample, a processing for 
extracting a resource from a free list in which usable 
resources shared in the system are queued, initializing 
the resource as extracted and chaining it to a resource 
alocation list of a given process. In (hat case, the 

10 shared resources which need the mutually exclusive 
control or management are the free list and the 
resource alkxataon list 

When the processing mentioned above is to be 
reaf zed only by setting the preempt-disabled interval, it 

IS is then necessary to set the preempt-disabled interval 
so that it extends from a time point "preceding to con- 
tacting the tree lisf' to a lime point at which "the 
resource has been chained to the resource allocation 
lisr. To this end. processings (la) to (Sa) mentioned 

!o below win have to be cam'ed out 

(la) Setting the preempt-disabled state. 
(2a) TaMng out the resource from the free list 
(3a) Initialization of the resource. 
26 (4a) Chaining the resource to the resource alloca- 
tion list for the processes. 
fSa) Clearing the preempt-disabled state as set. 

At this Juncture, it Is noted that the time taken for ini- 
30 tialization of the resource is not alwE^ short. In fact, 
time in the order of several ten milliseconds Is taken 
solely for the Initialization of a memory upon memory 
aRocation internally of the operating system. Accord- 
ingly, when the mutually exclusive control is to be real- 
35 ized only by setting the preempt-dlsalsled intennl. as 
menHoned above, there may arise such situation that a 
given one process occupies the CPU tor an extended 
time, which wil result in degradation in the response 
peifonnance on the real-time basis, eventually exerting 
w adverse influence to the periodical drivatoillly of the con- 
tinuous media processing. 

As ttiB means for ooping with the above proUeme, 
ttie processings mentioned above may be modified or 
reanangedasfblfows: 

« 

(lb) Setting tiie preempt-disabled siata 
(2b) Taking out the resource from the free list 
(3b) Clearing the preempt-cEsabled state as set. 
(4b) Initializing the resource. 
so (5b) Setting the preempt-disabled state. 

(6b} Ctiaining the resource to the resource aloca- 
tion list for the processes. 
(7b) Clearing the preempt-disabled stale as set. 

ss The alxive processings can certainly satisfy the 
necessary condition from the view point of the mutual 
exclusive control or management. Besides, the duration 
of the preempt-disabled interval can be reduced to ca. 
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10 ^sec.. while in Vrte resource inHialization processing 
(4b), the right of using the CPU can be transfen-ed to 
other process. Thus, the real-time response perform- 
ance of the system can be improved. Unfavorably, how- 
ever, tliere may arise a problem when the proc^ 
executing the resource initialize processing (4b) is 
externally forced to terminate in the course of executing 
tNs processing. 

In general, most of computer systems are equipped 
with afunctlon for slopping externally process eocecutlcHi 
for coping with overrunring of a program Accordingly, 
when the process fficecuting the processings mentioned 
above is forced to terminate by other process by resort- 
ing to the fwcive terminate function mentioned above, 
then the resource initialized by the processing (4b) may 
become a tree resource belonging lo none of the man- 
agement lists. As the result of Ihle, such situallon may 
arise in which the operating system can not recover the 
resource when the process is tern^nated, which in turn 
means that the resource used l>y the process termi- 
nated forcltily becomes unusable for ever. In order to 
evade tfie problem, there may be conceived a method 
of initializing the resource in the state where the 
resource Is chained to the free list or the resource allo- 
cation list. In that case, however, the duration of the 
preempt-disabled interval period is substantially equal 
to that of the preempt-disabled period covering the 



According to the teaching of the Invention, it Is 
declared by the process in precedence to tlie use of the 
shared resource that the process is not forcibly termi- 
nated. Parenthetically, in the description which follows, 
expression "process is not aborted" or the like is used, 
which means that the process is not forcibly terminated, 
and prevention of the process from being forcibly termi- 
nated is expressed as "abort disabling " or the lilw. Thus, 
'the state in which a process is proirented Irom being 
aborted" may be GMpressed as "abort-disdUed stale' or 
the ike. AddWonally, the process is "preempt-disabled". 



which mean that the process is protected against ii^r- 
ruption or suspension of the processing or tasic exe- ' 
cuted by that process. At the end of the use of the 
shared resource, the process is cleared from the 

5 preenpt-dis^ed state. Upon conpletion of all the 
processings for the shared resource, it is declared by 
the process that it may be forcibly terminated, which is 
expressed as 'clearing the process from the abort-disa- 
bjed state' or simply as 'clearing of the abort-disabled 

10 state' or so. Further, thetlme period or interval interven- 
ing between the dborl-disable dedaiaiioR and the 



method, it is equally ooncervabla to prepare separately 
a list for managing the resources under initialization, 
wherein the resource undergoing the processing (4b) is 
chained to this list. However, this method is disadvanta- 
geous in that overhead involved in the initialization 
processing vicreases because of an increased nuntoar 
of times the list-chain changing processing has to be 
perlomied. 

In the light of ttw state of the art descrbed above, 
the Inventor of the present appHcaSon has developed a 
process executing method which is capable of process- 
ing the shared resource without affecting adversely the 
periodical drivat>ility of the continuous media processing 
by making use of the preempt control method. 

Accordingly, it is a first ot)ject of the present inven- 
tion to provide a process executing method for execut- 
ing processes which use a shared resource in a 
computer system designed for continuous meda 



'abort-disabled hterval'. When a request for the forcive 
termination of a process is issued during the aborl-dis- 
is abled period or interval, execution of the process is con- 
tinued until the processing to be executed during the 
aboit-disabled period has been completed. When the 
abort-disabled state is cleared, the prwess is (oreibly 



In a prelen'ed mode for carrying out the invention, a 
sole process dedicated for coping with such situation 
that the shared resource is used by a process over a 
prolonged duration is provided in the system. Further, 
fOr sending the requests for uswig the shared resource 
to the sole process, there is provided a queue. The 
other process destined for performing the continuous 
media processing issues a shared resource use request 



ical driving, and tipon completion of tfie proceesing for 
so the shared resource, the periodicai driving is vafidated. 
The request mentioned above is registered in the 
queue. Provision of such dedicated process can ensure 
that it is always only one process in the system that can 
peribrm the processing fbr the shared resource. Thus, - 
SB tie processing tor the shared resource can be effectu- 
ated in the preempt-enabled state, whkih In tum means 
that the processing fior the shared resource can be exe- 
cuted In parallel with the periodically driven process or 
processes. 

40 . .. By virtue of combinations of the tvro process exe- 
cuting methods mentioned above, a pluraiity of proc- 
esses which use the shared resource can be executed 
without exerting any noticeable adverse influence to the 
processes driven periodically in the multiprocessing 

46 environment in which a plurality of processes can run in 
parallel wHh one another. 

On the other hand, in the case of the method 
according to which the identifier is i^aced in or assigned 
to the hash tuncGon as a key to determine the index 

BO 'Index' of the resource management data containing 
the address of the resource for malang access to the 
resource, there arise problems mentioned below in exe- 
cuting such processing which has to process a large 
amount of data at a high speed on a real-time basis 

55 wfnie alkicating a CPU time at every predetermined 
interval as in the case of the muHi-media data process- 
irig. 



6 



(1) When a plurality of processes make simultane- 
ous access to one dHta. colllsior) of the hash vaiue& 
will take place in the accessing method using the 
hash function, which makes it necessary to search 
the overflow area while following pointers until the 5 
identifier of the resource as searcfied is found. 

Further, when the Identifier is found, it is neces- 
sary to search the process management data t)y 
following with the pointers mtil the process identi- 
fier is found in order to check wh^her or not the 10 
ptooess attetnpttng to make access (0 the shared 
resource has really the access right (i e., the right of 
accessing the resource). Consequently, overhead 
involved In the processing Incre^es considerably 
while the time taken for the memory access 15 
becomes too long to be useful for effective repro- 
duction of the data. 

(2) In the system In which the user application 
unlodffi the resource, ttie operating system has to 
follow or trace the pointers of all the process man- 20 
agement data in otder to acquire the identifier o» the 
process using the resource and release the pioc- 
esB management data as toind wNle messaging to 
the Individual processes that the resource can not 

be used. During the period lor the search men- as 
tloned above and for the execution of succeeding 
procesangs, all the accesses from the user appli- 
cations to the resource are disabled or inhbited. 
Consequently, in the case where the resource deal- 
tocatian processing takes place and in the system 30 
in whld^ there exist a pluraUty of processes to be 
processed on a real time basis, overhead amolved 
in searching the processes sharing the resource to 
be deallocated and eocecuting the succeeding deal- 
foeaifon processing will Increase oonsiderBbly. In ss 
that case, the real-time proceesing isverydifffoulttD 
realize or rendered impossible. 

In the HgM of the foregoing, it is a second object of 
the present hmenUon to prcwide an accessing method « 
which is capable of reducing the overhead involved In 
the translation between the Identifier and the address 
while sustaining the access right control function of the 
conventional metfiod and decreasing the time or period 
during which the access to the shared resource for exe- 49 
cuting the process terminating processing Is disabled. 

For achieving the above and other objects whkih 
will become apparent as description proceeds, it is 
taught according to an aspect of tlie present invention 
ttiat an identffier composed of address information and so 
generatiofi identifying inforiiiatlon of a resource is 
assigned to a resource upon generation thereof and at 
the same time the generation identifying information is 
stored at a leading location of the resource. The gener- 
ation Identifying information Is exti'acted from an idenG- ss 
fler transfen'ed as an argument of a system call issued 
by a user applicatfon upon making access to the 
resource. TVie extracted generation identityins infoma- 
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tion Is compared writh the generation Identifying informa- 
tion stored in the resource at the leading location 
tiiereof. Access to the resource is enabled when coinci- 
dence is found between both the generation identifying 
information while disabled when discrepancy Is found 
between both the generation identifying infomtation. In 
this way, the access right to the resource can be control- 
led solely by comparing both the generation Identif^ng 
information. 

The above and other objects, features and attend- 
ant advantages o( the present invention will more easily 
be understood by reading the tbikwing descriptnn of 
the prefen'ed embodiments thereof taken, only by way 
of example, in coniurxition wHh the accompanying diaw- 



BRIEF DESCRIPTION OF THE DRAWINGS 

tn the course of tiie description which follows, refer- 
ence is made to the drawings, In which: 

Rg. 1 is a schematic diagram tor illustrating a oon- 
ventional scheme for controlling access right to a 
shared resource in a multiprocessor computer sys- 
tem known heretofore; 

Fig. 2A is a view for illustrating schematically a 

structure of resource management data employed 

for resource management in a computer system; 

Rg. 2B is a view tor illustrating schematically a 

structure of process management data empfoyed 

tor process managemert in the con^putar system; 

Rg. 3 Is a flow chart for Illustrating a conventional 

resource allocation processing; 

Rg. 4 Is a flow chart for illustrating a conventional 

resource access processing; 

Rg. 5 is a flow chart for illustrating a conventional 

resource deallocation processing: 

Rg. 6 is a schematic diagram showing a group of 

modiles and data required for canning out the 

method according lo the erhbcxSment ol the present 

invention; 

Rg. 7 is a fkw chart for illustrating a processing 
procedure carried out according to the enfbodlment 
of the invention shown in Rg. 6; 
Fig. 8 is a tlow chart illusb-ating a processing proce- 
dure of an abort disable functton (21) shown in Rg. 
6; 

Fig. 9 is af tow chart ilusbBling a processing proce- 
dure of a preempt dsaUing lundlon (32) shown in 
Rg.6; 

Rg. 10 is a flow chart illustrating a processing pro- 
cedure of a dteaUed-preenpt dear functfon (33) 
shown in Fig. 6; 

Rg. 11 is a ffow chart illustrating a processing pro- 
cedure of a disabled-abort clear function (22) 
shown in Rg. 6; 

Rg. 12 is a schematic diagram showing modules 
empkved in carrying out the process executing 
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method accoiding to another embodiment of the 

irwention; 

Fig. 13 is a flow chart for illustrating a processing 
procedure of processes (210-21 2) shown in Fig. 1 2; 
Fig. 14 is a flow chart for illustraling a processing s 
procedure performed by a processing request mes- 
saging module (300) shown in Fig. 12; 
Rg. 15 is a flow chart for illustrating a processing 
procedure performed by a serializer process mod- 
ule (220): 10 
Fig. 16 Is a flow chart for ilustrating processings 
performed by processing completion messaging 
module (310-312) shown in Fig. 12; 
Rgs. 17A, 17B and 17C are views showing sche- 
matically major structural conponents partaking In is 
the control or management of access right; 
Fig. 18 B a flow cfnrt for niustiating generally a flow 
of resource access processing: 
Fig. 19 is aflow chart tor Illustrating schematicaiiy a 
resource allocation processing; zo 
Fig. 20 is a flow chart for llluGtrating a generation 
identifying information creating (makejdnf) 
processing: 

Rg. 21 is a flow chart for illustrating a resource area - 
acquisition (allocjd) processing; . u 

Fig, 22 is a flow chart for illustrating a idenlif ler ere- ' 
ating (make_id) processing; 
Fig. 23 is a flow chart for llluelraling a resource 

Fig. 24 is a flow chart for Illustrating a resource- so 
deallocation proceesing. 

DESCRIPTION OF THE PREFERRED EMBODI- 
liAENTS 

■• ss 

Now, the present invention will be deeaibed in 
detail m conjunction with what is presently considered- 
as preferred or typical embodiments thereof by refer- 
ence to the drawings. In the foliowing description, like 
reference characters designate Dke or correspmding to 
parts throughout the several views. 

Figure 6 shows schematically a set of modules and 
data required for carrying out a method according to an 
embodiment of the present invention. 

in the figure, reforence numeral 10 denotes a proc- 4S 
ess management table 10 for oontrolling or managing 
processes. In the process management laUe 10, there 
are held an abort request flag 11 . an ^Mrt-disabied flag 
12, a counter 13 for counting abort disabings nested. 
Further, reference numeral 20 denotes a process man- so 
agement module for controlling or managing processes, 
21 designates an interlace function for setting the abort 
disabling. 22 denotes an interface function for clearing 
the abort disabling, and 200 denotes a process which 
requires the processing for a shared resource. Further- ss 
more, refereiwe numeral 40 denotes a functton which 
uses a shared resource provided in the process 200 
and which holds work areas 23 and 37. AddrtionaHy. ref- 



erence numeral 30 denotes a preempt contro! module 
which is based on the teaching of the invention dis- 
doeed in Japanese Patent Application Na 8-97997. 
More specifically, the preempt control module 30 
includes a schediier 31 . a preempt disable function 32, 
a disabled-preempt clear function 33, a scheduting 
request flag 34, a preenpt-disabled flag 35 and a coun- 
ter 36 for counting the preempt disablings nested. 

Rgure 7 is a flow chart for illuslrating a flow of con- 
trols for the abort disabling and the preempt disabling in 
a process for realizing a feature of the present invention. 
When processing relating to the shared resource is to 
be executed, the function 40 included in the process 
200 destined for executing the above-mentioned 
processing inltlally MiibHa its own process from being 
aborted by using the abort disable function 21 (step 
1300). Immediately before ueing the shared resource, 
the function 40 inhibits Its own process fivm being 
preempted by using the preempt disable luncfion 32 
held in the preempt control module 30 (step 1301). 
whereon the processing which makes use of the shared 
resource is executed (step 1302). Upon completion of 
the processing tor the siiared resource, the disabled 
preenpt is Instantaneously released or cleared with the 
aid of the disabled-preempt dear function 33 held in the 
preempt control module 30 (step 1303). At this juncture, 
it should be mentioned that setting of the preempt-dlsa- 
bled Interval (or preempt-disaUed section in the light of 
the control flow) extending from the preempt disabUng id- 
the disabled-preempt clearing (corresponding to the 
section extending from the Step 1301 to the step 1303) 
is limited to such processing for the Shared resource 
which Is terminated within a time exerting no adverse 
influence to the periodical driving performance, e.g. a 
time not longer than 10 % of a minimum time required 
tor managing the periodical driving. During a period pre- 
ceding to the subsequent dedaradion of the preempt 
disabling, there prevails a preetrpt-enabled state where 
processings require relatively a lot of time such as ini- 
tialization for the allocated resource or the liw Is exe- 
cuted (step 1 304). During this period, execution of the 
process 200 may be temporarily Interrupted (or sus- 
pended) while allowing other processes to be sched- 
uled. When the processing for the shared resource 
becomes necessary again, the process 200 sets itself 
once more to the preefr^-disabled stats (step 1305). 
When the processing for the shared resoume (step 
1306) comes to an end, the preempt disabling is 
released or cleared (step 1307). Upon completfon of all 
the processings, the dnrt disabling Is cleared finally by 
resorting to the use of the disabled-abort deas fuiction 
22 (step 1308). 

In the case of the example illustrated in Fig. 7, the 
preempt-disabled interval makes appearance twice dur- 
ing the period extending from the abort disabling to the 
disabled-abort clearing. In actual applications, the 
number of such preempt-disaUed intenals may be 
more than three mduswe thereof. 
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Figure s is a flow chart illustraGng in detail an inter- 
nal processing of ttie abort dis^ling procedure (1300) 
mentioned above bf reference to Fig. 7. Execution of 
the processing shown in Fig. 8 Is effectuated by using 
the abort disable function 21 . To this end, the abort dis- 
able function 21 checks at first whether the abort-disa- 
bled flag 12 held in the process management table 10 
managing the process 200 is in the OFF-state or not 
(step 1400). When the abort-disabled flag 12 is OFF, 
then the cU&ort disable function 21 sets the abort-disa- 
bled flag 12 to the ON-state (step 1401). Subsequently, 
the abort disable function 21 increments the value of the 
counter 13 by one (st^ 1402}. The procedure shown in 
Fig. 8 is indivisible in execution thereof. 

Figure 9 Is a flow chart illustrating In detail internal 
processing of the preempt disabling procedure (1301. 
1305) merrtioned above by reference to Fig. 7. The 
processing shown in Fig . 9 Is executed by means of the 
preempt disable function 32 shown in Rg. 6. At first, the 
preempt disable function 32 checks whether the 
preempt-disabled flag 35 held In the preempt control 
module 30 is in the OFpHState or not (step 1500). When 
the preempt-disabled flag 35 is OFF, then the preempt 
disable function 32 sets the preempt-disabled flag 35 to 
the ON-stats (step 1501). Subsequently, the preempt 
disable function 32 increments the value of the counter 
36 by one (step 1502). The whole procedure shown in 
Fig. 9 is omcuisd IndnrisUy. 

Figure 1 0 Is a flow chart IllusHallng In detail internal 
processing of the disabled-preempi clearing procedure 
(1303, 1307) mentioned above by reference to Fig. 7. 
Execution of the processing shown in Fig. 10 is In 
charge of the disabied-preempt dear function 33 shown 
in Fig. 6. At first, the disaWed-preempt clear function 33 
checks whether or not the nest value (desaibed hwein- 
after) ol the function transferred as the first argument 
coincides with the value of the counter 36 (step 1600). 
Unless coincidence is found, then an abnorma% 
processing is canriad out. On the other hand, wher) the 
ooinCiderKe Is found, ttte value of the counter 36 Incor- 
porated in the preempt control module 30 is decre- 
mented by one (step 1601). When the value of the 
counter 36 resulting from the decrementation is positive 
(plus), then the processing is terminated intact (step 
1602). On the contrary, hi case the value of the counter 
36 Is zero a negative (minus), the preempt-disabled 
flag is set to the OFF-state (step 1603). Subsequently, 
the scheduling request flag 34 held intemally of the 
preempt control module 30 is checked (step 1604). 
When iHs flag is OFF, then the processing is termi- 
naled. On the other hand, when the schec&iling request 
flag 34 is in the ON-state, the scheduler 31 is activated 
(step 1605) to thereby validate the execution of the 
scheduling processing for the process. 

Figure 1 1 is a flow chart illustrating in detail internal 
processing of the disabled-^»rt clearing procedure 
(1308) menlianed above by reference to Fig. 7. The 
processing shown in Fig. 11 is executed with the aid of 
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the disablsd-abat clear function 22 shown in Fig. 6. At 
first, the dlsaUed-abort clear function 22 checte 
whether or not the nest value (described hereinafter) of 
the function transferred as the first argument coincides 

5 with the value of the counter 13 (step 1700). Unless 
ooinddence is found, then an abnormality processing is 
periormed. On the other hand, when coincidence is 
confirmed, the value of the counter 13 incorporated in 
the process management table 10 managing the pnoc- 

10 ess 200 is decrerrtented by one (step 1701). When the 
value of the counter 13 resulting from the decrementa- 
tion is positive (plus), the processing is terminated intact 
(step 1702). By contrast, in case the v^ue of the coun- 
ter 13 is 2ero or negative (minus), the abort-disabled 

IS llag is set to the OFF-state (step 1 703). Subsequently, 
the abort request flag 1 1 held internally of the process 
management ^e 10 is checked (step 1704). When 
this flag is OFF, then the processing is terminated. On 
the other hand, when the abort request flag 1 1 is ON, 

20 the process management module 20 is activated (st^ 
1705) to thereby waidate the ocecution of the abort 
processing for the process 200. 

Furthermore, in case the processing shown in Rg. 
1 1 IS terminated in the OFF-state of the abort request 

25 flag 11 , the process management module 20 activates 
the scfieduier 31 incorporated in the preempt control 
nnodule 30 to perform the process rescheduling 
praceaeing. 

Referring to Fig. 6, the interval or period duriig 

30 which the abort-disabled flag 12 remains In the ON- 
state. i.e.. the period from a time point at which the abort 
disable function 21 is called to set the abort-disabled 
flag 12 to the ON-state to a time point at VKhich the disa- 
Ued^rt clear function 22 is called to set the abort- 

35 disabled flag 1 2 to the OFF-state represents the abort- 
dteabled inten/al. The abort-disabled flag 12 Is in the 
0FF<8tale when the process is created or generated 
and set to the ON-state only when the abort disable 
function 21 is called. In case the Ibrcive termination of 

40 the process 200 occurs during the abort-disabled inter- 
val during which the abort-disabled flag 12 remains in 
the ON-state as set by the abort disable function 21 
called by the process 200, the process management 
module 20 executes only the processing for setting the 

« abort request flag 11 to the ON-state while allowing the 
proceeelng of the process 200 to be continued. The (or- 
dve tennlnatlon of the process 200 is validated when 
the abort-dnaUed flag 12 is set to the OFF-state by the 
disabled-abort dear function 22 caRed by the process 

so 200. 

Further, referring to Fig. 6, the interval or period 
during which the preempt-disabled flag 35 remains in 
the ON-state, i.e., the period extending from a time point 
at which the preempt disable function 32 is called to set 
55 the preenfjt-disabled flag 35 to the ON-state to a time 
point at which the disaUed-Fxeen^pt dear function 33 is 
c^ed to set the preempl-disabled flag 35 to the OFF- 
state represents the preempt-disaUed Intenal. The 
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preempt-disablGd flag 35 is in the OFF-state when the 
system is activated and set to the ON-slate only when 
the preempt disable function 32 is called. In case the 
echeduline request tor the other pnx»ss(es) occurs 
during the interval in v»hlch the preempt-disabled <lag 35 
remains in the ON-state as set by the preempt disable 
function 32 called by the process 200, the schedule 31 
executes only the processing for setting the scheduling 
request flag 34 to the ON-state v¥hBe allowing the 
processing of the process 200 to be continued without 
scheduling the other process(es). When the preempt- 
disaUed flag 35 Is set to the OFF-state by the disaUed- 
preennpt clear function 33 called by the process 200, the 
scheduler 31 sets the scheduling request flag to the 
OFF-state and suspends the execution of the process 
ZOO while allowing other processes to be scheduled. 

Referring to Fig. 7, in the interval or section extend- 
Ing fl^ the step 1 301 to the step 1 303 and in the inter- 
val or section extending from the step 1305 to the step 
1307, the preemption is disabled, which in turn means 
that the right of using the CPU (Central Processing Unit) 
Is never transferred to other process. Thus, it Is only the 
running process that can use the shared resource. In 
other words, any other process is inhibited from using 
the shared resource, whereby the exclusive control or 
management of the resource can be realized, which 
makes it possSile to perform the continuous media mul- 
tiprocessing using the shared resource. Additionally, 
because abortion is disabled during the interval span- 
ning over the steps 1 300 to 1 308, any process acquired 
the resource is caused to vanish due to Vie iorcive ter- 
n^on. Thus, the resource is posifively prevented 
from falling In such stale lhat It can not be utilized for an 
indefinite period. 

The doort (fistMing as well as the dieabled-abort 
clearing is effectuated through the medium of interfacee 
mentioned below, respectively. 

(Function Name) 

abort_disable(*level) 

(Argument) 

level: the depth of the nest formed by a pair of the 
instant function now under consideration and the finc- 
tion 'abon.enablft" is returned. 

(Elucidation) - 

The function now of concern can mal<e the currently 
executed process transit to the abort-disabled state. 
This function and the function "abort_enable" may be 
issued in a pair during the section or period spanning 
over the transition to the abort-disabled stale in 
response to the issuance of this function and the reslo- 
ration to the abort-enabled state in respome to the issu- 
ance of the function- 'abortjenable'. This means that 



the pair oi the function now of concern and the function 
'abort_enable' can be nested. The function now of con- 
cern and the function 'abort_enable' issued internally of 
the nest make no state transition between the abort-dis- 
5 aUed state and the abort-enabled state. The argument 
level' reflects the depth of such nested state. 

(Function Name) 

10 d}ort_enable(level) 

(Argument) 

level: he level of the nest returned from tfie function 
IS "aborUJIsable" which oonsfitutes the counterpart to be 
paired with the instant ftmction is designated. 

(Elucidation) 

20 Ttie function of concern can malw the currently 
executed process be restored to the abort-enabled 
state The function now of concern (i.e., "abort_enable ") 
and the function "abort_disable" may be issued in a pair 
during the section or period spanning over the transition 

w to the abort-disabled state in response to the Issuance 
of ttie function 'abortjdisable'' and the restoration to the 
abort-enabled state in response to tie issuance of the 
instant function. This means that the pair of the function 
"abart_disable' and the function now of concern 

so 'abort.enable' can be nested. The function 
"abort.disaUe" and the function now of concern Issued 
internally of the nest make no state transition between 
the abort-dsaUed slate and the abort-«iabled state. 
The (ngument 'level' designates or r^reaenls the 

35 depth of such nest, i.a, the value of "level" due lo the 
issuance of ttie counterpart function "aborlLdlsable'. 
This value is held by the operatitq system as well. Thus, 
discrepancy of this value with the depth of the nest 
specified by the argument, the so-called enor return 

« lakes place. 

When the function 40 included in the process 200 
uses the abort disable function 21, the function 40 
stores in Hs own work area 23 the currerrt depth of the 
nest returned from the abort disable function 21. For 

4s issuing the dteefcled-abort dear function 22. the value 
stored h ttie work area 23 is designated or specified as 
the argument of the fundkin 40. The dtaaUed-abort 
dear function serves to oompve the value mentioned 
above with the current depth of the nest to valMate the 

50 enor return unless ooinddenoe is fbund between both 
the values mentioned above. By virtue of this function, it > 
is possitile to detect easily such a programming bug that 
the disabled-abort clear function which is to constitute 
the counterpart of the atxirt disable function In a pair, Is 

55 absent. 

The preempt disable processing and the disabled- 
preempt dearing processing can be carried out by mak- 
ing use of the dtsflUed-preempt desing interface and 
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the disabled-preempi clearing interface disclosed in 
Japanese Patent Application No. 8-97997 mentioned 
hefeinbsfore. Namely, th? following inteftoces are 
employed. 

(Function Name> 

preempt_di5able{*leval) 

(Argument) 

level: the d^h of the nest formed by a pair of the 
instant function now of concern (i.e., liraampLdlsable') 
and the funcBon Tpreempt.enable" ie relumed. 

(Buddat'on) 

TTie function now of concern mal«s the currently 
executed process transit to the preempt-disabled stale. 
This function "preenq:rt_disable" and the function 
"preempLenaUe' not be issued fai a pair dirlng the 
section or interval intervening between the transition to 
the preempt-disabled state in reeponse to the issuance 
of this function and the restoration to the preempt-ena- 
bled state in response to the issuance of the function 
"preempLenaUe". This means that the pair of the fuic- 
tion now of concern and the function "preemptjanable'* 
can be nested. The function new of concern and the 
function >eenpt.enable' issued internally of the nest 
make no stale transition between the preeinplKlisalbled 
state and the preemp^enabled stata The argument 
'level" refleclE the depth of such nest. 

(Function Namd> 

preempl_enable(leveO 

(Argument) 

level: the level of the nest returned by the function 
'preempLtliBQble" which is to constitute a oounteipart 
of the pair of the instant iundian is designated. 

(Bucidation) 

TTie function of concern can make the currently 
executed process restore to the preempt-enabled state. 
The function ipreempUSsable" and this function may 
be Issued in a pair during the Interval or perkxl spanning 
over the transition Id the preempt-disabled state in 
response to the issuance of the function 
"preempt_disable" and the restoration to the preempt- 
enabled state in response to the issuance of this func- 
tion. This means that the pair of the function 
"preempt_disabie" and the function of concern can be 
nested. The funclkjn ipreempljcllsable* and the func- 
tion now of concern issued internally of the nest make 
no state transition between the preempt-disabled state 



and the preempt-enabled state. The argument "level" 
designates the depth of such nest, i.e.. the value of 
"level'' obtained due to the issuance of the counterpart 
function "txeempL disable'. The depth of the nest is 

5 heW by the operating system as well. Thus, discrepancy 
of this value with the depth of the nest specified by the 
argumem, the so-called error return takes place. 

When the fundkm 40 Included in the process 200 
uses the preempt disable function 32, the function 40 

10 stores in its own work area 37 the cunrent depth of the 
nest relumed from the preempt disable functlan 32. For 
issuing the disabled-preempt dear function 33, the 
value stored In the work area 23 is designated or speci- 
fied as the argument of the function 40. The disat)led- 

15 pieenrpt dear fundion serves to compare the value 
mentnned above with the current depth of the nest to 
thereby validate the error return unless coincidence is 
found between both Vie values mentioned above. By vir- 
tue of this fundion, such a programming bug can easily 

so be deteded that the disabled-preempt dear function 
which Is to constitute the counteipart of the preempt 
disable function in a pair is absent. 

Next, description will turn to an embodiment of the 
inventton which is direded to a method of executing a 

25 process using a shared resource in th e case where the 
shared resource is used for a prolonged duration. 

In the process executing method according to the 
inslant embedment of the iiwentton, a periodicaly 
driven process performs processing for acquiring the 

so resource as requi'^d by using the process SMCuting 
method deecribed betow in the state not periodically 
driven in precedence to Ihe start of the periodical driv- 
ing. After completion of the above processing, the proc- 
ess slarls to be driven periodically. Once the periodical 

35 driving has been started, no processing is performed for 
acquiring the resource in the process executing method 

Rgura 12 shews modules which are required for 
carrying out the process executing meifKxl aocoidlng to 
« the instant enotxxUment of the invenlton. 

ki Rg. 12, reference numerals 210 to 212 denote, 
respecdvaly, those processes which are requesting use 
oi the shared resource, and numeral 220 denotes the 
sole process that is authorized 1o perform the process- 
es ing for a specilto shared resource. This process 220 will 
hereinafter be caled the serializer process. The serial- 
izer process 220 is resident witNn dte system. A 
numeral 300 denotes a processing request messaging 
module for messaging to the serializer process 220 the 
50 processing requests issued by the processes 210 to 
212, respectively In correspondence to the serializer 
process 220. the sole processing request messaging 
module 300 is provided and constantly resident within 
the system as in th e case of the process 220. Reference 
ss numerals 310 Id 312 denote, respedlvely, processing 
completion messaging modules for transfen-lng the 
process completnn message from the serializer proc- 
ess 220 to the processes 210 to 212, wherein the 
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processing complelion messaging modules 310 to 312 
are assigned to Ihe processes 210 to 21 2, respectively, 
upon generation thereof or upon issuartce of the 
processing request therefrom. The processing request 
messaging module 300 and the processing completion 
messaging modules 310 to 312 have internally queues 
400, 410 to 41 2, respectively. 

t^lext, processings executed in the system shown in 
Fig. 12 will be described by reference to fkm ch^ 
shown in Figs. 13 to 16. 

Figure 13 isaflowchartforiluBtratlngaproceGSMris 
executed by each of the processes SlO to 212 which 
need the processing for the shared resourca More spe- 
cifically, each of the processes 210 to 212 issues a 
processing requesting message to the processing 
request messaging module 300 for requesting the 
procesGino of the serlalizer process 220 whEch is capa- 
ble of accessing the shared resource (step 1800). Hie 
process 210 or 211 or 212 which has issued the 
procesang request is immediately set to the state wait- 
ing for reception of the processing completion message 
from the associated one of the processing completion 
messaging modules 310 to 312 after completion of the 
processing request message. When the processing 
completion is informed from the processing completion 
messagirrg module 310 or 311 or 312 (step 1801). the 
process 210 or 21 1 or 212 fetches the processing com- 
pletion message from the queue 410 or 41 1 or 412 pro- 
vided in the associated one Ol the processing 
completion messaging modulesSIO to 312 (step 1802), 
whereupon the processing for the shared resource as 
requested by one of the processes 210 to 212 comes to 
an end. 

Figure 14 is a flow chart for iltustrating the process- 
ings performed by the processing request messaging 
module 300. It is first to be mentioned that the process- 
ing request messa^g module 300 is constantly in ihe 
state ready for reception of the processing request mes- 
sage. Upon reception' of the processing request mes- 
sage (step 1900). the processing request messaging 
module 300 places the processing request message in 
the queue 400 In the order as the message is received 
(step 1901), whereon the processing request messag- 
ing module 300 informs the serializer process 220 ttiat 
the processing request has been issued. 

Figure 15 is a flow chart for illustrating the process- 
ing perfarmed by flie serializer process 220 which is the 
sole process capable of performing processing fbr the 
shared resource. Similarly to the processing request 
messaging module 300, the serializer process 220 is 
constantly in the state wailing for reception of the 
processing request message. Upon reception ol the 
Information concerning issuance of a processing 
request from the processing request messaging module 
3O0 (step 2000), the serializer process 220 fetches or 
receives Itia processing request from the queue 400 
Incorporated in the processing request messaging mod- 
ule 300 (step S001) to perfsrm the processfng on or for 



the shared resource in accordance with the request 
(^ep 2002). After completion of the processing for the 
shared resource, the serializer process 220 informs the 
processing conpletion and the result of the processing 

5 to one of the processing completion messaging mod- 
ules 310 to 312 which is associated with one of the 
processes 21 0 to 212 which has issued the correspond- 
ing processing request (step 2003). In tiie meanwhile, 
the serializer process 220 checks whether the next 

10 processing request is placed in the queue. If sa the 
serializer process 220 performs the processing for the 
shared resource in accordance with that processing 
request. Othenwise, ttie seriafizer process 220 resumes 
the state ready for reception or acceptance of the sue- 

IS ceeding or next processing request (step 2000). 

Figure 16 is a flow chart fbr ilustrating the process- 
ings performed by the processing completa'on messag- 
ing module 310 or 31 1 or 312. Each ol the processing 
compleUon messaging modules 310. 311 and 31 2 is set 

^ to the state waifing for Ihe message informing the 
processing completion simultaneously with issuance of 
the processing request from the associated one of the 
processes 21 0 to 21 2. Upon reception of the processing 
completion from the serializer process 220 (step 2100), 

2s the processing completion messaging module places 
(he processing compleBon message and the result of 
the processing in the associated one of the queues 410 
to 412 (step 2101), virhereupon the processing comple- 
tion messaging module 310 or 311 or 312 issues Ihe 

30 message indicating the processing completion to the 
relevant one of the processes 210 to 212 which has 
issued the processing request (step 2102). 

In the case of the system illustrated in Fig. 12. i1 is 
assumed that there eocisl three processes 21 0, 21 1 and 

as 212 which request the processing for the shared 
resource. It goes however without saying that the con- 
tents of the processings are essentially invariable even 
when the number of the processes requesting the 
shared-resource involving processing is less or more 

40 than three. 

At this juncture, it should be mentioned that the 
serializer process 220 in the system shown in Fig. 12 
operates constantty in the preempi-enabled state. 
Further, it should be again mentioned that tine proc- 

415 ess 210, 211 or 212 perform the resource acquiring 
processings mentioned above (Fig. 13) before the peri- 
odical driving thtereof is started. In other words, the 
process ^10, 211, 212} acquires Ihe resource data in 
the state irrelevant fo the periodical driving which is 

50 started only afterthe resource has been acquired due to 
the processing described above. 

By adopting the process executing method based 
on the serializer process described above, the exclusive 
conbol (i.e., mutual exclusion conft-oi or management) 

55 need not be peribrmed because the process which can 
pertbrm processing direcfly on or for the shared 
resoume is only one, i.e., the serializer process. Tlius. 
by virtue of Ifte arrangement that (he processing for the 
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shared resource is performed by the preeirfit-enabled 
independent process dedicated to the processing lor 
HiB shared resource, process execution can be aocom- 
pliGhed without exerting any influenoe to the periodical 
driving perfonnanoe (or periodical drivabilit^ of other 5 
processes partaking in the continuous media process- 
ing. 

As is apparent from the foregoing description, a 
shared resource can be shared t?y the Indlviduaf proc- 
esses Involved bi the continuous media pnxeesing or to 
the ike without exerting any influence to the periodical 
drtvabHity of the processes In the multlpracessing envi- 
ronment in which the sttared resource Is made use of. 

Next, description wll be made of an accessing 
method according to another embodiment of the is 
present invention. 

§1. Configuration 

Major components or modules partaMng In an 
access right control will be descrbed by reference to 
Figs. 17A.17B and 17a 

An resource ident»ier eOO shown In Hg. 17A is an 
argument of 64 bite contained in the system call issued 
by a user application for using the same in the access to ss 
the resource. Of the 64-bit argument the leading 32 bits 
are used for identifying a starting or leading address 
601 ot a resouroe 608 while thetralBng 32 bits constHute 
generation identifying intormation 602. The resource 
identifier 600 is generated upon ciieafion of the resource so 
and used for making access to the resource until the 
resource is released or deal-located. 

A resource generation counter 603 stiown in Fig. 
17B is created for each of the processes upon genera- 
tion thereof and serves as a counter for recording the ss 
number of times the resource Is generated. The count 
value 604 of the resource generation counter 603 Is set 
to the initial value of zero and incremented by one every 
time the resource is created. 

Qenerafion identifying information 605 shown in 40 
Fig. 17C contains leading 16 bits representing a count 
value 606 of the resource creation counter with the trail- 
ing 16 bits represertting a process identifier 607. 

Hereinafter, Ihe resource which contains the gener- 
atkm identifying information 609 at a leading or starting 45 
location thereof wil be referred to as the resource 608. 

§2. Outline of Resource Access Processing of User 
Application 

so 

Rgure 18 Is a fkw chart ilustrating a flow of pro- 
gram fbr executing tiie resource access processing car- 
ried out by the method according to the instant 
embodiment of the invention, which will be described 
below stepwiB& 55 

(1) In a step 2200, a user appltoaiion issues a sys- 
tem call requesting a process generating process- 



ing to the operating system, which responds thereto 
by creating a resource generation counter 603 for 
the process as generated. 

(2) In a step 220 1 . the user applicatkm issues to the 
operating system a system call fbr the resource 
dtocation processing. 

(3) In a step 2202, the user application issues to the 
operating system a system call requesting an 
access processing to the resource allocated in the 
step 2201. 

(4) In a step 2203. the user applksaHon issues to the 
operating system a system call requesting an deid- 
kxatkm processing of the resource allocated in the 
step 2201. 

In the following, the processing for each of the sys- 
tem calls mentioned above will be descrised in detaS. 

§2.1. Resouroe Allocatian Processing 

Rguie 19 Bhowe a flow chart for illuslrallng the 
reeource aflocation procesaing step 2201 shown in Rg. 
18. The resource generation counter is Incremented by 
one (step 2300 in Fig. 19), whereon generation identify- 
ing information creating or making processing 
"makejdinf" is executed (step 2301), which Is then fbl- 
lowed by a step 2302 in which a resource area afloca- 
tion (or memoiy area acquislfion) processing 
':allac_mBm" is executed and a step 2303 of creating an 
IdentHler "hnkBjd' is executed. Thereafter, the genera- 
tion identifying information is stored at leacfing 32 bits of 
the resource area as returned (step 2304). 

§2.1.1. Generation Idenlifying Information Creating 
(make_idinf) Processing 

Figure 20 shows a flow chart for illustrating the gen- 
eration identifying information creating processing In the 
step 2301 sttown in Fig. 19. Hereinafter, this processing 
wll also be referred to as 'make.idinT processing. The 
generation identifying infomwtion is created by a pair of 
the resource generation counter value and the process 
identifier of the process destined for the resource gener- 
ation. Refen-ing to Rg. 20, the process identifier is first 
acquired (step 2400), whereon the reeource generation 
counter value Is placed in the leacBng 16 bits whie a 
random number value as generated is stored in the trail- 
ing 16 Uts, to thereby aaate or make the 32-bit genera- 
tion Mentifying informatfon (step 2401). The generation 
identifying information as created is returned (step 
2402). 

§2.1.2. Resource Area Acquisition (Memory Allocation) 
(altoc_mem) Processing 

Rgure 21 shows a flow chart for illustrating the 
resource acquisition (or allocation) processing In the 
step 2302 shown in Rg. 19. This processing will also be 
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referred to as "alloc.mem" processing. Because the 
resource area is oonstHuted by a generation identifying 
information area and a resource area, 9)e resource area 
size added with tlie generation ideirtilying infwmation 
data size of 32 bits IG determined (st^ 2500), whereon 5 
the resource area of the size as determined is allocated 
(step 2501). Thereafter, the leading address of the 
resource area (memory area) is returned (step 2S02}. 

S2.1 .3. Identifier Creating (make.id) Proceesing w 

Figure 22 shows a flow chart for illustrating the 
identifier creating processing in the st«p 2303 shown in 
Fig. 19. Hereinafter, this processing will also be refen'ed 
to as "makejd' processing. The Identifier is constituted is 
by a pair of the resource address and the generation 
identifying information. The address of the resource 
acquired in resource area allocation or "alloc_mem" 
processing (step 2302) is placed at leading 32 bits while 
the generaflon Identifying informafion created in the so 
generation identifying inlbrnnation creating 'mal<e_id" 
processing (step 2301) is placed at the trailing 32 bits, 
to thereby create the identifier of 64 bite (etep 2600). 
The identifier as created is returned as the argument for 
use in making access to the resource (step 2601 ). ss 

^.2. Resource Access Processing 

Figure 23 shows a flow chart for illustrating a 
resource access processing corresponding to the step so 
2202 in Fig. 18. Referring to Fig. 23. the leading 32 bits 
of the identifier received as the argument of the system 
call issued by the user application are extracted to 
thereby define the resource address while the trailing 32 
bite are extracted fbr defining the generafion identifying ss 
infonnation S1 (st^ 2700). Subsequently, the leading 
32 bits are read out from the resource on the bastB off 
the resource address to define flie generation identily- 
ing inJbrmafion S2, i.e., "read_mem" information (step 
2701), whereon the generation identifying information *) 
S1 and S2 as extracted are compared with each other 
(step 2702). Unless the comparison results in coinci- 
dence, the access to the resource is not performed, and 
an en'or message is returned (step 2703). On the other 
hand, when the above ooniparison results in coinci- « 
dence, then the access processing to the resource is 
perfbmned (step 2704). 

§2.3. Resource Deallocation Processing 

so 

Figure 24 is a flow chart for illustraling a reeouiK 
deallocation processing. 

Similarly to the resource access processing (step 
2202 shown in Fig. 18). in the resource deallocation 
processing (step 2203 shown in Ftg. 18). the leadng 32 ss 
bits of the identifier received as the argument of the sys- 
tem call issued by the user application are extracted to 
define the resource ack^ress while the trailing 32 bits are 



extracted for defining the generation identifying inlbrma- 
tk>n SI (step 2800). Subsequently, the leading 32 bits 
are read out from ttie reeouice to define the generation 
identifying infbnriation S2 'read_mem" processing (step 
2801). Thea the generation identifying informatran 81 
and 52 mentioned alMve are compared with each other 
(step 2802). Unless the comparison results in coinci- 
dence, the resource is not deallocated and a cone- 
sponding error message is returned (step 2803). On the 
other hand, when the above comparison results in coin- 
cidence, then the resource dealocation processing Is 
periomied (step 2804). 

By virtue of the methods described abovei, there 
can be obtakied advantageous effects mentioned 
below. 

(1) As is obvious from the description concerning 
the resource access processing (§2.2.). the 
address for accessing the resource is contained in 
the identifier which is the argument of the system 
call issued by the user application to the operating 
system. Thus, it is possible to make access to the 
resource by using the identifier in place of using the 
hash function for the translation between the identi- 
fier and the address. Consequently, overhead 
involved by the use of the hash fundian can be 
diminished. 

(2) LeTs suppose that a process A and a process B 
share a resource and that the process A has Issued 
a system call far dealocating the resource X. In that 
case, in the conventional system, the operating sys- 
tem searches the identifiers contained in the 
resource management data by following the point- 
ers, starting firom the index derived by using the 
hash function to thereby determine the address of 
the resource to be dealloGated. Further, other proc- 
esses sharing the resource X is searched to 
release all the process management data as found 
and issue a message indicating that the resource X 
is bwalid. In the meantima the operating system 
inhbils or disables all the accesses to the shared 
resource from the user applications. 

By contrast, accortfing to the methods of the 
invention, the address of the resource can be 
obtained for unloddng the resource without need 
Ibr fUkMring the pointers far acquiring the address 
of the resource because the address has already 
been contained In the identifier of the resource X to 
be deallocated. AddltfanaHy. it is apparent from the 
previous description concerning the resource deal- 
locafion processing (§2.3.), the operating system 
controls or manage the resource access right on 
the tjasis of only the result of comparison between 
the generation identifying information 81 contained 
in the identifier assigned to the resource X arxl the 
generation identifying infamnation S2 stored in the 
leading of the resource X. Thus, the task imposed 
on the operating system is only the deallocation of 
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the resource X. 

In this manner, the duration of the state in 
which the access to the resource Is dtsabied and 
which maltes appearance between Vhe successive 
process completion processings can be reduced to 
only me Wme involved in dealtocaSng the resource 
X. 

(3) In conjunction with the resource deallocation 
processing descrbed above, it is again assumed 
that a process C generates a resource Y and alio- 
cates the created reaource Y to the address having 
been allocated to the resource X in the slate in 
which the resource X is deallocated or released. In 
that case, the operating system Issues to l>>e proc- 
ess B no information or message indicating that the 
resource X has been deallocated. Consequently, 
there may arise such situation that the process B 
tries to mal<e access to the resource Y on the basis 
of the address information contained in the identi- 
fier of the process B. However, because the identi- 
fier contains not only the address Informaticn but 
also the generation itlenlifying iiikxinalion and 
because the generation identifying infbrmation is 
different between the identifier assigned to the 
resource X and the identifier assigned to the 
resource Y, the process B trying to mal« access to 
the resource Y with hs own identifier can not access 
the rescMirce Y. In this manner, flie Illegal access 
can be poslUvBly Inhibited or disabled. 

§3, Other Embodimerrts 

Many features and advantages of the present 
invention are apparent fomi the detaled description and 
thus it is Intended by the appended claims to cover all 
such features and advantages of the system MMch fall 
within the true spirit and scope of the invention. Further, 
since numerous modifications and comt>lnatlons will 
readily occur to those skilled In the art it is not Intended 
to limit the Invention to the construction and operation 
illustrated and descrbed. Accordingly, all suildble modi- 
ficalions and equivalents may be resorted to, falling 
within the spirit and scope of the invention. Modifica- 
tions of the embodiments described above will be men- 
tioned below. 

§3.1. System Utilizing System Clocit 

Upon starting-up of the system, a system 
dock is generated for holding the time as lapsed on a 
10-|1 second basis. 

When a resource is created, the value of the sys- 
tem dodk is fetched as ttie generation identifying infor- 
mation which is then stored at a leading address of the 
resource. An identifier of 64 bits is created which is 
composed of 32 MSB (more significant bits) corre- 
sponding to the address of the resource and 32 LSB 
{less signRlcant bits) conresponding to the generation 



identifying information. 

For malang access to the resource, the generation 
identHying Infbrmation Is extracted from the identifier 
transferred as the argument of tiie system call from the 

5 user application to the operating system, whereon Vne 
detracted generation identifying information is com- 
pared with the generation identifying infbrmation stored 
at the leading or starting address of ttie resource. When 
this comparison results in coincidence, the access to 

10 the resource is enabled, i.e.. allowed. On the contrary, 
when the comparison shows discrepancy, tiie access to 
the resource is disabled or inhUted wHh an mor mes- 
sage being returned. 

IS §3.2. System Ulizing Counter 

When the system Is activated, a single 32-bit coun- 
ter is generated in the system for counting the number 
of times which resources are generated, and an initial 

so value "0" is inputted to the counter as tiie generation 
idm illfyng information. 

Upon creation of a resouice, the above-mentioned 
generation identifying information k incremented by 
one and stored at the starting or leading address of the 

25 resource. Subsequentiy, a 64-bit Identifier Is created 
which includes more sig nif leant 32 bits corresponding to 
the address of tiie resource and less significant 32 bits 
corresponding to the generation idsnWyIng Information. 
For accessing the resourca, the reeouice access 

30 processing is peribrmed by using the identifier men- 
tioned above simlarly to the processing described in the 
section §3.1.. 

Further, tiie resource accessing methods described 
above by reference to Figs. 17A to 23 allow to structure 

35 a safe system which Inhibits or disables the invalid 
access to the shared resource by applying Uie access- 
ing method to tiie processing steps 1302 and 1306 
shown In Fig. 7. This shared resource accessing 
mettiod will be described below. 

« For the shared resource allocation, the processing 
aiustrated in Fig. 19 is executed tor effecting flie shared 
resource allocation. At that time, the Identifier assigned 
to tiie shared resource Is held to check tiie validity of the 
shared resource by using tMs Identrier upon access to 

45 the shared resource. 

Next, a shared resource accessing method will be 
descrbed below. 

When tiie processings 1302 and 1306 shown In 
Fig. 7 are executed for carrying out the shared resource 

so access processing, processing illustrated in Fig. 23 is 
executed for validating tiie access to the shared 
resource. At first, before making access to the shared 
resource, the generation identifying information (602 In 
Fig. 17A) stored in the identifier is compared with the 

55 generation identifying information (609 in Fig. 17A) of 
ttie shared resource (step 2702 in Fig. 23). 

When coincidence is found between botii the gen- 
eration Mentifying formation, itistiiendecidfldthattiie 
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identifier of the shared resource is valid, i.a, ttie 
resource address (601 in Fig. 17A) contained in the 
identifier is valid. Accordingly, access is made to the 
shared resource Isy using the resource address to per- 
form the processing for the shared resouroe. 

On the contrary, when discrepancy is found 
between both the generation identifying Information 
mentioned above, this means that the identifier of the 
shared resouce is invalid. More specifically, assuming, 
by way of example, that dscrepancy of the generation 
iderrtrfying itifomiaft>n occurs In the processing step 
1306 shown in Fig. 7. «iis means that the shaiwl 
resource is deallocated for some reason during the 
preempt-enai>le Interval intervening between the 
release of the preen^ disabled-stale (step 1303 in Rg. 
7) In succession to the compleb'on of the processing 
1302 shown in Fig. 7 and the next preempt di 
(step 1305 In Fig. 7). Thus, the address of the re 
(shared resource) as contained in the identifier is 
invalid. Consequently, the access to the shared 
resource Is suspended and an error processing (step 
2703 In Fig. 23) is carried out. In the error processing, 
the preempt disal:ling or inhibition and/or abort disa- 
bling may be cleared as occasion requires. 

Owing to the processing method descrbed above, 
deallocating of the shared resource carried out outside 
of the preempt-disat^ed interval can be detected. 
Basidas, the access to the Invalid resource whidi may 
occur in accompanying the above-mentioned shared 
resource deallocating can be prevented tor thereby pro- 
tecting the resource from being destroyed. In this way, it 
Is pcGBible to structure a system capable of processing 
the shared resource with enhanced security even when 
the preempt enable interval is set In the shared 



As will now be appreciated from the foregoing 
descriptnn, according to the teachings of the invantion 
disclosed herein, overhead involved in the translation 

between the address and the identifier as well as search 
for checking the presence^absence of the access right 
can be reduced with the access performance being cor- 
respondingly enhanced. Besides, the resource-access 
disabled interval or section taldng place upon comple- 
tion of the pnscess can be shortened. Additioially, the 
resource can be protected against destruction due to 



imparted with no resource access right. 
Claims 

1. In a computer system in which a plurality of proc- 
esses can run in parallel, a process executing 
method for executing a given one of said plural 
processes by acquiring one shared resource (608) 
for said given one process, using said shared 
resouroe (608) and deallocating said shared 



said method comprising the steps of: 



acquiring said shared resource (608) for use by 
said given one process after disabling abortion 
and preemption of said given one process; 
clearing said given one process from preempt- 
disabled state and disabling preemptirai of said 
given one process alter processing for said 
shared resource; 

clearing said given one process from the 
preempt-disabled state as welt as from the 
abort-disabled elate after said shared resource 



given one process; and 
executing a fbrdve t^mhatfon request issued 
for said given one process during a period in 
which said given one process has been in the 
abort-disabled sUte. 

A process executing method according to dalm 1 , 
wherein a queue for registering those proc- 
esses issued respective requests is provided for 
use of said shared resource (608), 

said method further comprising the step of: 



a multiprocessing environment a . 
leading one of the processes registered In said 
queue and issued respective requests for use 
of said shared resource {608}; and 
driving periodcally procesting relating to said 
process ailer oomplelfon of eoncuOon tlwaof 
and sxeculing serially the processes registered 
in said queua 

3. A method of accessing a single resource in an 
operating systen. comprising the steps of: 

assigning to a reeource (608) an identifier (600) 
oompoead of address infonnation (601) and 
generation identif^g information (602) of said 
resource (608) upon generation thereof; 
storing said generation identifying Information 
(609) at a leading location of said resource 
(608); 

extracting generation identifying Information 
(602) from an identifier (600) transferred as an 
argument of a system call issued by one user 
application far accessing said resowce (608); 
comparing the eKtracted generation identifying 
mining 
»(e08) 

at a leading localfon thereof; and 
enabling a 

coincidence is found between said generation 
identifying information (602 and 609) while dis- 
abling access to said resource (608) when ds- 
crepancy is found between said generation 
identifying information (602 and 609). 



4. An accessing method according to claim 3. 
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wherein said generation idenWyng informa- 
tion is a piece of information conceming a lime sad 
resource was generated. 

6. An accessing method accoidffig to daim 3, wherein s 

said operating system Includes only one coun- 
ter (603). and 

said method further comprises the steps of: 
incramentlng a counter value {604} of said to 
counter (603) by one upon generation of a 
resource and using said counter value (604) as 
said generation identnying Inlbnnation (605). 

IS 
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FIG. 1 
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FIG. 3 
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